Size Change: +929 B (0%)

Total Size: 1.39 MB

_{compressed-size-action}

Flaky tests detected in c053a1e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4945275915
📝 Reported issues:

• [Flaky Test] should display (capture the) text from the currently active link even if there is a rich text selection #36495 in specs/editor/various/links.test.js

Do we want to keep the current transform UI in Inspector?

My instinct is that's something to consider separately. There is an icon-button UI there, and also this dropdown which looks a little tired:

On Group blocks the 'Orientation' UI is also a transform:

It might be good to consolidate all of these different transform methods, but yeah, likely a separate consideration.

If we have a maximum number(ex 4) we could show them in a list

Are we aware of any examples where a block has more than four variations? Do we need to worry about this just yet? Flyouts would probably make sense and afaik the components team are currently researching that.

Looking at a couple of specific blocks:

Group

1. It's strange to see Quote as a transform option, but I guess that's a separate issue?
2. 'Variations' is kind of a technical term, I'm not sure we need the heading.
3. I'd be tempted to prioritise the variations group over the columns/cover/unwrap group. 'Unwrap' should probably be 'Ungroup' but I guess that's separate too.

Terms

1. Again I'd prioritise the variations – this is probably a good rule of thumb.
2. It's strange to see the Product taxonomies here. I'm editing my Post template so there's no practical use for them in this context. I appreciate this might be tricky but do you have any ideas how we might exclude contextually incompatible variations? To be clear: Categories ↔ Tags makes sense, as does Product Tags ↔ Product Categories. But Categories ↔ Product Categories doesn't.

I've love to hear thoughts from other @WordPress/gutenberg-design team members.

Thanks for working on this Nik!

If we have a maximum number(ex 4) we could show them in a list

Are we aware of any examples where a block has more than four variations? Do we need to worry about this just yet?

Right now in core, no. But this can be the case for Social Icon and probably some other blocks, when we enable this. This is an API that will pick up such variations(transform scoped) and show them there, so if any third party blocks have many of them, will automatically render there.

It's strange to see Quote as a transform option, but I guess that's a separate issue?

Yes

'Unwrap' should probably be 'Ungroup'

This is an API for other blocks too, like Quote and that's the reason for the more generic label.

It's strange to see the Product taxonomies here

That's something different as we don't have any context for variations/blocks right now. I think this is more connected to the issues about where to show specific blocks in all places(even the Inserter).

Adding variations to the Transform to drop down looks like a good idea to me.
As some will use the Transform drop down to make the adjustment, while others will use the top sidebar icons to adjust. There are just different preferences to how to accomplish something. There is also a lot of space in the Transform drop down and can also be easier to use compared to the top sidebar settings area. I would at the moment not set a limit to example 4, but instead see how things develop and change to make the drop down easier to navigate. I like the Transform drop down you have made Nik.

Another aspect with this is if the Transform drop down needs an even bigger redesign which needs to be more thought through, but that is for another time.

I’m curious if variations should be treated any differently than transforms.

The experience, and resulting expectation, of using either a transform or a variation is the same. I don’t think it’s necessary to call them out separately; perhaps just prioritized higher than transforms.

“Transform” and “Variation” are more technical terms anyhow (why I suggested “Turn into” previously #42202).

I’m curious if variations should be treated any differently than transforms.

In the case of the use case described in this PR, maybe the difference is not useful.

Zooming out a bit, however, I feel like the block transforms interface (both the one in the inspector, but primarily the dropdown from the block toolbar) hasn't been as creatively explored as it might have been. Essentially transforming one block into another can be thought of as an opportunity to view a variety of possible layouts. A quote might get a ton more impact by becoming a pullquote, or an image might benefit from text-overlay of a cover.

We are a bit limited there with transforms, through poor quality block previews, lots of work to still do on flyout menus, and some duplicate interfaces muddling things up. At the same time, this transforms interface also needs to accomplish the most basic writing flow task: transform a paragraph to a heading.

I still think there's an opportunity for a larger creative push on transforms, as described above. But a more useful near term solution there may be to refine pattern transforms first. That is, select 2 paragraphs and an image, and get suggestions for compatible patterns it can transform into. Can be both in the dropdown, but it can also easily be here:

Keeping pattern transforms in mind as probably the first big visual transforms push, maybe single block transforms can just be grouped together? (Also, let's remove "Unwrap" in favor of having only "Ungroup" in the ellipsis menu soon)

But a more useful near term solution there may be to refine pattern transforms first. That is, select 2 paragraphs and an image, and get suggestions for compatible patterns it can transform into.

There is no good way to do that easily currently. There is a mechanism for transforming from patterns(implemented here), but there are many boxes to check in order to find matches:

1. Patterns need to declare the blockTypes prop for blocks they want to support
2. They need to be simple blocks(no innerBlocks)
3. All selected blocks are matched with a Pattern's block

So while it's possible for certain cases and already in block switcher, it's quite hard and I don't think there are lots of patterns right now that are made with the above in mind.

Having said that, this PR's main purpose for me is to decide on how to better organize the transforms, even if that would mean to explore augmenting some APIs. I started with the variation transforms, but we should have a clear vision on where we want to go and act accordingly.

I still think there's an opportunity for a larger creative push on transforms, as described above.

I agree—that'll be very neat—though I lean towards that effort being separate from transforming between a single blocks variations (what this PR is attempting).

I don't think there's a difference experience-wise if I want to change my "Tags" block into a "Categories" block, or even a "Post Date" block. I'm turning one thing into another, at the singular block level. Selecting a variation from that popover isn't transforming the block in a programmatic sense, but it is experientially.

I'm proposing we move forward on this PR, but remove the separate MenuGroup to instead have variations prepended to the list of "transforms".

And as a follow-up consider #42202, as well as removing Columns and Group as editor-wide transforms. We already have Group/Ungroup and columns doesn't seem like a common entry-point after-the-fact.

To be clear, that's entirely separate from this issue, and not blocking or even urgent. But I want to make sure it's ticketed both for separate conversation and followup, so if there isn't yet an issue (anyone know?), I'm happy to create one.

There's this issue here: #45841

Took this for another spin, I'm getting this error here, on block multi-select:

Fixed! Additionally I prepended the variation transforms to the list. I'll see to the tests now.